Ken Schwaber的《Scrum Guide》這本小冊子，原本是英文的，這裡提供中文的，以供日後復習和參考。**
自從上世紀90年代初期，Scrum方法就已經應用於開發複雜的產品。本指南介紹瞭如何應用Scrum構建產品。Scrum不是一種過程，也不是一項構建產品的技術，而是一個框架，在這個框架裡可以應用各種過程和技術。Scrum的作用就是讓開發實踐方法的相對功效顯現出來以便隨時改進，同時也為開發複雜產品提供了框架。
Scrum是以經驗過程控制理論為依據，採用迭代、增量的方法來提高產品開發的可預見性並控制風險。Scrum的三大支柱支撐起每個經驗過程控制的實現。
高透明度確保管理結果的人看得到那些影響結果的過程方面。這些過程方面不僅要透明，而且那些被觀察到的方面也必須被充分了解。這就是說，當某人檢驗某個過程並認為完成了某些任務時，這個完成必須等同於他們的完成定義。
開發過程中的各方面必須做到經常性的檢驗，以確保及時發現過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能容許的程度，那麼就會出現問題。幸運的是，軟件開發並不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水平和勤勉程度。
如果檢驗員經檢驗發現過程中的一個或多個方面不滿足可接受標準，並且最終產品是不合格的，那麼檢驗員就必須對過程或是材料進行調整。調整工作必須盡快實施以減少進一步的偏差。
Scrum中有三個進行檢驗和適應的時刻：（PS：Sprint指迭代）
① 每日例會（Daily Scrum）是用來檢驗朝向Sprint目標的工作進程，調整以優化次日的工作價值。
② Sprint評審和計劃會議是用來檢驗朝向發布目標的工作進程，調整以優化下一個Sprint的價值。
③ Sprint回顧會議是用來評審完成的Sprint，並確定什麼樣的調整可以使下一Sprint的效率更高、結果更令人滿意和更易於工作。
Scrum框架包括一組Scrum團隊和與其相關的事物：時間盒、工件和規則。
Scrum團隊的目標是提高靈活性和生產能力。為此，他們自組織、跨職能，並且以迭代方式工作。每個Scrum團隊都有三個角色：
① Scrum Master，負責確保成員都能理解並遵循過程；
② Product Owner ，負責最大化Scrum團隊的工作價值；
③ Team，負責具體工作。團隊包括的開發人員具備開發所需的各種技能，負責在每個Sprint結束之前將產品負責人的需求轉化成為潛在可發布的產品模塊。
Scrum利用時間盒實現規律性。被時間盒限定的Scrum要素有：發布計劃會議、Sprint計劃會議、Sprint、每日例會、Sprint評審會議和Sprint回顧會議。Scrum的核心是Sprint，即貫穿於開發工作中保持不變的一個月（或更短時間）迭代。所有的Sprint都採用相同的Scrum框架，並且都交付潛在可發布的最終產品增量。Sprint的交替沒有間隔期。
Scrum主要的工件 (Artifacts)：
**產品待辦事項列表 (Product Backlog)**是囊括了開發產品可能需要的所有事項的優先排列表。
**Sprint待辦事項列表 (Sprint Backlog) **包含了在一個Sprint內將產品待辦事項列表轉化成最終可交付產品增量的所有任務。
燃盡圖 (Burndown Chart) 是用來衡量剩餘的待辦事項列表。發布燃盡圖衡量在一個發布計劃的時間段內剩餘的產品待辦事項列表。Spritn燃盡圖衡量在一個Sprint時間段內剩餘的Sprint待辦事項列表條目。
其他可选的Scrum工件包括产品远景 (Product vision)、发布计划 (Release Plan和障碍日志。
規則將Scrum的時間盒、角色和工件聯繫起來。對於Scrum規則的描述將貫穿整個指南。例如，Scrum規則規定：只有團隊成員，即承諾將產品待辦事項列表轉換成產品增量的人員，才可以在每日例會上發言。在下面“提示”框中描述的實現方法並不是規則而是建議。
提示：當規則未明確時，Scrum的使用者們要自己想出如何去做。不要試圖去尋找完美的解決方法，因為問題通常變化的很快。相反的， 嘗試一些做法並觀察效果如何。Scrum經驗本性中的檢驗和適應的特性會指導你。
Scrum團隊包括ScrumMaster、產品負責人和團隊。Scrum團隊成員被稱為“豬”，其他人被稱為“雞”。“雞”沒有權利要求“豬”如何去開展工作。“雞”和“豬”的比喻來自於以下的故事：
一隻雞對一頭豬說：“我們合夥開家飯店吧！”豬想了想，說：“那我們給這個飯店起什麼名字呢？”雞說：“雞蛋和火腿！”豬回答到：“那還是算了吧，你要做的只是下幾隻雞蛋，我把命都搭上了！”
ScrumMaster與客戶和管理層共同確定和具體化產品負責人人選。ScrumMaster負責教授產品負責人如何進行工作。產品負責人應當了解如何以Scrum優化產品開髮帶來的價值。如果他們不能做到這點，那麼我們認為ScrumMaster是負有責任的。
ScrumMaster負責確保Scrum團隊遵守Scrum價值、實踐和規則；幫助Scrum團隊和整個組織實施Scrum；通過指導和引導，教授Scrum團隊更高效工作、生產出高質量的產品；幫助Scrum團隊理解並採用自管理和跨職能。但是，ScrumMaster不對Scrum團隊進行管理，團隊是自組織的。
提示：ScrumMaster可以是團隊的成員，例如，他可以是承擔Sprint任務的開發人員。但是，當他需要在排除障礙和執行任務之間選擇權衡的時候，這種身兼二職的情況常常會對做決定帶來矛盾。ScrumMaster絕對不能是產品負責人。
產品負責人是管理產品待辦事項列表、確保團隊工作價值的唯一責任人。他負責維護產品待辦事項列表，確保每個成員明晰列表內容、明確哪些條目具有最高優先級，從而了解下個需要開發的條目。產品負責人是一個人，而不是一個委員會。可能會有一些委員會向產品負責人提出建議或影響他的決策，但要想改變某條目的優先級必須先說服產品負責人。實施Scrum的企業可能發現這樣會對他們制定優先級和需求的方法產生影響。
提示：對於商業開發，產品負責人可能就是產品經理。對內部開發而言，產品負責人可能來自其業務會被該產品自動化的職能部門經理。
為保證產品負責人的工作取得成功，組織中的所有人員都必須尊重他的決定。任何人都不得要求團隊按照另一套優先級開展工作，團隊也不允許聽從任何人帶有威脅恐嚇性的指令。產品負責人所作的決定需要明確的包括在產品待辦事項列表的目錄和優先級中。這就要求產品負責人竭盡全力，同時也使其成為一個費心費力但又值得去做的角色。
提示：產品負責人可以是團隊成員，承擔開發任務。但是這樣可能會牽掣其精力，影響產品負責人和利益相關人協調工作。但是，產品負責人絕對不能是ScrumMaster。
開發人員組成的團隊負責在每個Sprint將產品待辦事項列表轉化成為潛在可交付的功能增量。團隊同時是跨職能的；團隊成員必須具備創造產品增量所需要的技能。團隊成員常常具備如編程、質量控制、業務分析、架構、用戶界面設計或數據庫設計等的專業技能。然而，團隊成員所共同分享的技能即訪問需求並將需求轉化成可用產品的能力，往往比那些專業技能更重要。因為是架構師或設計人員而不願意編碼的人不適合成為團隊成員。每個人都盡心盡力參與，即使需要學習新技能或鞏固現有技能。團隊中沒有頭銜的概念，這一規則無例外。團隊也不允許包括測試或業務分析等在特定領域工作的子團隊。
團隊同時是自組織 (self-Organizing) 的。任何人，包括ScrumMaster都沒有權利規定團隊如何將產品待辦事項列表轉化成可交付的功能增量，而是由團隊自己確定。每個團隊成員利用自己的專業技能，解決遇到的問題。這種協同配合提高了團隊整體的效率和效力。
團隊的理想規模是7個（加或減2個）人。如果成員少於5人，那麼相互交流就減少了，團隊的生產力也會下降。更重要的是，團隊在Sprint中可能會受到技能限制，從而導致無法交付可發布的產品模塊。如果成員多於9人，那麼成員之間就需要太多的協調溝通工作。大型團隊會產生太多複雜性，不便於經驗過程控制。但是，我們也遇見過一些超過規模上或下限人數的團隊取得成功。產品負責人和ScrumMaster這兩個角色不計入成員人數，除非他們也是“豬”。
團隊的構成在Sprint結束時可能會發生變化，每次團隊成員的變化，都會降低通過自組織而獲取的生產力。因此，改變團隊構成時務必要謹慎。
Scrum中的時間盒包括：發布計劃會議、Sprint、Sprint計劃會議、Sprint評審會議、Sprint回顧會議和每日例會。
发布计划会议的目的是建立Scrum团队与组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题：“我们如何以最佳方式将愿景转化为成功的产品？我们怎样才能达到或甚至超越客户的满意度和投资回报？”发布计划确定发布目标、具有最高优先级的产品待办事项列表、重大风险和发布所包含的全部特性和功能。另外，发布计划会议确立大致交付日期和费用，如果没有任何变化就应当保持该日期和费用。因此，组织就可以检验开发进程，以每个Sprint为基础调整发布计划。
產品應用Scrum以迭代的方式構建，每個Sprint中都會創造出產品增量，通常先開發價值最高和風險最大的產品。產品增量隨著Sprint交替而完成，每個增量都是整個產品的可交付部分。當創造出足夠多有價值、對投資人有益的增量時，產品就可以發布了。
大多數組織已經有自己的發布計劃過程，並且在大多數過程中的大部分計劃已經在發布之初完成，而且也不會更改。在Scrum發布計劃會議上確立一個整體目標和預期結果。發布計劃會議通常不超過組織構建傳統發布計劃的15-20%時間。然而，Scrum發佈在每個Sprint評審和計劃會議上都執行及時計劃，同時，在每日例會上執行每日及時計劃。總的看來，Scrum發布可能比傳統的發布計劃耗費略多的工作。
發布計劃會議需要為發布估算並優先排列產品待辦事項列表。完成這項工作的技巧很多，但都不屬於Scrum的範圍，雖說如此，這些技術仍有其使用價值。
一個Sprint就是一個迭代，Sprint是以時間盒限定的。在Sprint中，ScrumMaster負責確保不出現任何影響Sprint目標的變化。團隊構成和質量目標在Sprint中均保持不變。Sprint包括，或者說由Sprint計劃會議、開發工作、Sprint評審會議和Sprint回顧會議組成。Sprint一個緊跟一個進行，之間沒有任何時間間隔。
項目旨在完成某個目標，對於軟件開發而言，其目的在於構建一個產品或系統。每個項目都包括構建目標的定義、構建計劃、工作完成進度和最終產品。每個項目都應該制定範圍，即計劃精準的時間範圍。如果時間過長，某些定義可能會發生變化，另外也會牽扯進很多變量，因而引發巨大的風險等等。**Scrum框架適合開發週期不超過一個月的項目，項目過於復雜勢必會使開發週期延長，從而增加風險。**至少每個月應該針對項目的可預見性進行控制，這樣每個月都可以遏制項目變得不可控製或不可預測而產生的風險。
提示：如果團隊發現承諾的任務過多，可以和產品負責人溝通，以減小Sprint 中選定的產品待辦事項列表範圍。如果團隊發現有富餘的時間，可以和產品負責人商議追加額外的產品待辦事項列表。
提示：當團隊剛剛開始使用Scrum，為期兩週的Sprint可以讓團隊在學習中進步，避免在不確定中掙扎。兩週時間的Sprint可以通過將兩個增量添加在一起，從而和其他團隊同步。
Sprint可以在Sprint時間盒結束之前取消。只有產品負責人才有取消Sprint的權力，但他做這樣的決定也可能是受到利益相關人、團隊或是ScrumMaster的影響。那麼，在什麼情況下必須取消Sprint呢？如果某個Sprint的目標過時了，那麼管理層就需要取消該Sprint。比如公司的發展方向，或是市場、技術等情況發生變化，這些變化都可能導致取消Sprint。總的來說，如果某個Sprint對於其所在環境來說失去價值和意義，那麼它就應該被取消。然而，因為Sprint週期都較短，所以很少發生取消Sprint的情況。
當某個Sprint被取消時，任何做完和“完成”的產品待辦事項列表條目都需要評審。假如有些條目已經相當於潛在可交付的產品增量，那麼它們是可以被取納的。其他的條目就都要復原到最初的估算，放回到產品待辦事項列表中去，任何相關工作就都被看作是徒勞的了。Sprint終止會消耗資源，因為每個人都需要在新召開的Sprint計劃會議中重新組合，開始另一個Sprint。Sprint終止對團隊的不利影響非常大，被終止的情況也非常的少見。
Sprint計劃會議制定迭代計劃。對於一個月為周期的Sprint，計劃會議的時間盒限定為8小時。對於較短的Sprint，計劃會議一般安排整個Sprint週期的5%時間。Sprint計劃會議的內容包括以下兩個部分：第一部分，4小時的時間盒中需要確定該Sprint將要完成什麼任務。第二部分，也是4小時的時間盒，團隊研究在Sprint內如何將功能構建成產品增量。
Sprint計劃會議包含兩部分內容：“做什麼”和“怎麼做”。一些Scrum團隊將這兩部分結合起來。第一部分，Scrum團隊處理“做什麼”的問題。產品負責人把具有最高優先級的產品待辦事項列表呈現給團隊，並一起決定接下來的Sprint中開發什麼功能。Sprint會議需要投入的要素包括產品待辦事項列表、最新的產品增量、團隊的能力和以往的表現。團隊自己決定選擇待辦事項列表的數量，因為只有團隊可以評估在接下來的Sprint內可以完成什麼工作。
選定產品待辦事項列表後，Sprint目標也就明確了。Sprint目標通過實現產品待辦事項列表來達到。Sprint目標為團隊提供指導，使團隊明確構建增量的目的。Sprint目標是發布目標的子集。
確定Sprint目標的原因是在功能方面為團隊留出一定的迴旋餘地。例如，上一個Sprint的目標可能是：“通過一種安全、可重獲的交易中間件實現客戶賬戶修改功能的自動化”。所以當團隊工作時，就會緊記這個目標。為了達到這個目標，團隊就需要實現該功能和技術。如果團隊感覺實現過程比預期的難度大，那麼就可以和產品負責人協商，只實現部分功能。
在Sprint計劃會議的第二部分，團隊需要處理“怎麼做”的問題。在Sprint計劃會議的第二個4小時時間盒中，團隊需要弄清楚如何將“做什麼”會議階段選定的產品待辦事項列表轉化成完成的增量。通常團隊會先以設計展開工作，設計過程中，團隊確定任務，這些任務就是將產品待辦事項列表轉化成可用軟件的具體工作。任務需要被分解，以便在一天之內完成。這個任務列表就是Sprint待辦事項列表。團隊自組織進行分配、承擔該列表中的工作，也可以在Sprint計劃會議或在Sprint中及時確定。
提示：通常，Sprint計劃會議上只設計出Sprint待辦事項列表的60-70%。剩餘部分後續完成，或者給出大體的估算並在Sprint中再分解。
產品負責人會參加Sprint計劃會議的第二部分，對產品待辦事項列表做一說明，並協助團隊權衡取捨。如果團隊認為工作量過大或太小，就可以和產品負責人重新協商、確定產品待辦事項列表。團隊也可以邀請其他人員參加會議，以尋求技術和領域建議。新組建的團隊常常在這次會議中第一次意識到：整個團隊要么一起成功，要么一起滅亡，沒有個體這個概念。團隊同時認識到必須依靠自己。正因為意識到這一點，整個團隊才逐漸自組織並形成自己的特色，真正成為一個團隊。
Sprint末尾時要舉行Sprint評審會議，一個月的Sprint通常對應4小時時間盒的評審會議。對於時間少於一個月的Sprint來說，該會議的時長不要超過整個Sprint的5%。在Sprint評審會議中，Scrum團隊和利益相關人溝通Sprint中完成了哪些工作。然後，根據完成情況和Sprint期間產品待辦事項列表的變化，他們確定接下來的工作。這是一個非正式會議，會議中進行功能演示，以促進下一步工作的互助與合作。
評審會議至少要包含以下因素：產品負責人確定完成了哪些工作和剩餘哪些工作。團隊討論在Sprint中哪些工作進展順利、遇到了什麼問題、問題是如何解決的。然後，團隊演示完成的工作並答疑。產品負責人和與會人員討論產品待辦事項列表，並根據不同的速率計劃出可能的完成日期。接著，整個團體就哪些工作已經完成，同時這對下一步工作有何意義進行探討。Sprint評審會議為接下來的Sprint計劃會議提供了寶貴的參考信息。
在Sprint評審會議結束之後和下個Sprint計劃會議之前，Scrum團隊需要舉行Sprint回顧會議。在這個3小時時間盒的會議上，ScrumMaster鼓勵團隊在Scrum過程框架和時間的範圍內，對自己的開發過程進行改進，使下一個Sprint的效率更高、更易工作。許多書籍都介紹了召開回顧會議的技巧。
回顧會議旨在對前一個Sprint週期中的人、關係、過程和工具進行檢驗。檢驗應當確定並重點發展那些進展順利的，和那些如果採用不同方法可以取得更好效果的條目。這些包括：Scrum團隊構成、會議安排、工具、“完成”定義、溝通方法和將產品待辦事項列表條目轉化成“完成”工作的過程。在Sprint回顧會議的末尾，Scrum團隊應該確定將要在下個Sprint中實現的有效改進方法。這些變化更適應於經驗檢驗。
團隊每天進行15分鐘的碰頭會就稱為Scrum每日例會。每日例會在各個Sprint都是在同一時間，同一地點進行。會議上，每個團隊成員需要匯報以下三個問題：
① 從上次會議到現在都完成了哪些工作； ② 下次每日例會之前準備完成什麼； ③ 工作中遇到了哪些障礙。
每日例會可以增強交流溝通、省略其他會議、確定並排除開發遇到的障礙、強調和提倡快速決策、提高每個成員對項目的認知程度。
ScrumMaster要確保團隊舉行每日例會，團隊則負責召開會議。ScrumMaster指導團隊執行規則來控制會議時間，並保證團隊成員進行簡短有效的匯報。ScrumMaster也執行“雞”不允許在會議上發言或以各種方式乾擾會議的規則。
每日例會不是進度匯報會議。這個會議是為將產品待辦事項列表條目轉化成為增量的人（團隊）召開的。團隊承諾實現Sprint目標和完成產品待辦事項列表條目。每日例會是檢驗朝向Sprint目標的進程（三個問題）。跟踪會議通常是對Sprint中的下一步工作進行調整，目的在於增加團隊實現目標的可能性。這是Scrum經驗過程中的重要檢驗和適應的會議。
Scrum的工件包括產品待辦事項列表、發布燃盡圖、Sprint待辦事項列表和Sprint燃盡圖。
產品待辦事項列表列出團隊正在開發的產品需求。產品負責人負責產品待辦事項列表的內容、可用性和優先級。產品待辦事項列表永遠不會是全面的，最初的版本只列出最基本的和眾所周知的需求。產品待辦事項列表根據產品和開發環境的變化而演進。待辦事項列表是動態的，它經常發生變化以確保產品更合理、更具競爭力和更有用。只要產品存在，產品待辦事項列表就存在。
產品待辦事項列表中包含產品開發和交付成功產品需要的所有條件和因素。表中列出了所有的特性、功能、技術、改進方法和故障修復等對未來發布產品進行的改變。產品待辦事項列表條目包含描述、優先級和估算的特徵。優先級是以風險、價值和必要性驅動的。評估這些特徵的技巧有很多。
提示：產品待辦事項列表條目通常是以用戶故事的形式展現。也有可能是用戶案例，但是用戶案例更適用於開發生命關鍵型或任務關鍵型軟件。
產品待辦事項列表按照優先級排序。優先級高的產品待辦事項列表需要立即進行開發。優先級越高，產品待辦事項列表越緊急，就越仔細斟酌，而且對其價值的意見越一致。優先級高的產品待辦事項列表更清晰直觀，細節信息比低優先級待辦事項列表的多，根據清晰的內容和詳盡的信息做出的估算就更具價值。優先級越低，細節信息越少，少到只能勉強辨認出該條目。
隨著產品的應用、價值的增加、市場的反饋，產品待辦事項列表變成了龐大、更詳盡的列表。因為需求不斷發生變化，所以產品待辦事項列表是個不斷更新的文檔。業務需求、市場形勢、技術和員工的變化都會引起產品待辦事項列表的變化。為了減少返工，只需要細化最高優先級的條目。在接下來的若干Sprint內將要進行開發的產品待辦事項列表條目是細粒度的，已經被分解過，因此，任何一個條目在Sprint內都可以被完成。
提示：Scrum團隊通常利用每個Sprint的10%時間，提煉產品待辦事項列表以達到上面的要求。當達到粒度要求時，產品待辦事項列表頂端的（最高優先級、最高價值）條目會被分解，分解後的條目適合在單個Sprint內完成。在提煉階段就已經對這些條目進行分析和考慮。當進行Sprint計劃會議時，這些高優先級的條目就能充分地被理解，也可以很容易挑選出來。
若干個Scrum團隊常常會一起開發某個產品。但描述下一步產品開發工作的產品待辦事項列表只能有一個。那麼這就需要使用產品待辦事項列表的特徵對條目進行分組。分組可以根據特性集、技術或架構進行。這也是Scrum團隊經常採用的一種組織工作的方法。
提示：驗收測試常常作為產品待辦事項列表條目的屬性。驗收測試經常以條目開發完成後應實現功能的可測試描述取代細節文字描述。
發布燃盡圖記錄了在一段時間內產品待辦事項列表的總剩餘估算工作量。估算工作量以Scrum團隊和組織決定的單位為標準，時間是以Sprint為單位。
在發布計劃會議中對產品待辦事項列表條目進行原始估算，之後創建條目。在產品待辦事項列表提煉階段，這些條目會被評審和修改。然而，對產品待辦事項列表的估算可以隨時更新，團隊負責所有的估算工作。產品負責人在協助和指導團隊權衡取捨時可能對團隊所做決定帶來一定影響。但是，最後的估算是由團隊進行。產品負責人總是留有一份最新的產品待辦事項列表/發布待辦事項列表燃盡圖。可以根據剩餘工作量的變化繪製一張趨勢圖。
提示：在某些組織中，向待辦事項列表中追加的工作任務比完成的還要多。這就可能造成繪製的趨勢圖曲線是水平甚者是上升的。為了應對這種情況並保證高透明度，在追加或減少工作量時，標記新的底線。只有工作量發生重大變化時才有可能需要增加或除去底線，而且也應該詳細記入文檔。
提示：趨勢圖曲線對於發布的前兩三個Sprint的可參考性也許不大，除非這些團隊曾經在一起工作過，對產品認識深刻，並且理解基本技術。
Sprint待辦事項列表包含團隊需要執行的任務，從而將產品待辦事項列表條目轉化成“完成”的增量。許多條目在Sprint計劃會議中已經定義。這些就是團隊確認的完成Sprint目標所必須做的工作。Sprint待辦事項列表條目必須被分解。進行充分的分解，那麼過程中發生的變化就可以在每日例會上得到理解。
團隊在整個Sprint內都會修改Sprint待辦事項列表，同時在Sprint內合併Sprint待辦事項列表。因為它是針對每個成員的任務，所以可能有時任務會偏多或偏少，亦或某項任務耗費的時間超出或提前於預期。**當出現新工作時，團隊需要將其追加到Sprint待辦事項列表中去。**隨著任務進行或者被完成，需要更新每項任務的剩餘工作估算小時數。如果某項任務失去開發的意義，就可以將其除去。在Sprint內只有團隊可以對Sprint待辦事項列表進行修改，也只有團隊可以對列表的內容或估算進行修改。Sprint待辦事項列表是高可見度的，是對團隊計劃在當前Sprint內完成工作的實時反映，並且，該列表只屬於團隊。
Sprint待辦事項列表燃盡圖展現的是當前Sprint內剩餘的Sprint待辦事項列表工作數量。創建該圖需要通過累計Sprint中每日待辦事項列表估算來確定剩餘工作量。Sprint內的剩餘工作量就是所有Sprint待辦事項列表的剩餘工作總量。每天對這些數據進行跟踪，並繪製燃盡圖，時刻顯示剩餘工作量。用線將圖上的點依次連接起來，團隊就可以控製完成Sprint工作的進程。所耗時長並不屬於Scrum的關注範圍，剩餘工作量和完成日期才是利益相關因素。
提示：盡可能在一大張紙上手繪燃盡圖，並將其懸掛在團隊工作區域內。因為團隊更傾向於去看一張大幅、清晰可見的圖，而不是去打開Excel表格或其他文檔工具。
Scrum的一個規則是關於每個Sprint目標的，即嚴格按照“完成”的定義開發潛在可交付的產品增量。
Scrum要求團隊在每個Sprint內構建產品功能的增量。這個增量必須是潛在可交付的，因為產品負責人可能會要求立即實現該功能。為了做到這一點，增量必須是最終產品完整的一部分，必須是“完成”的。每個增量都必須可以和前面所有增量累加起來，並且進行過徹底的測試，以保證所有的增量能兼容工作。
在產品開發中，宣稱功能已經完成會讓有些人認為這個功能至少擁有整潔的代碼、經過重構、進行了單元測試、通過構建、完成了驗收測試。另外一些人也許只認為該功能只是構建了代碼。如果每個人對“完成”定義的理解不同，經驗過程的另外兩個支柱也就無法發揮作用。當有人說某個工作“完成”了，每個人都需要明白“完成”的含義。
“完成”解釋了當團隊在Sprint中承諾“進行”某個產品待辦事項列表條目工作的意義。有一些產品不包含文檔，所以“完成”的定義不包含對文檔的要求。真正“完成”的增量包含了增量和其中所有產品待辦事項列表條目必須的分析、設計、重構、編碼、文檔和測試工作。測試包括單元測試、系統測試、用戶測試和回歸測試，另外還有非功能測試如性能測試、穩定性測試、安全性測試和集成測試。“完成”也包含所有的國際化工作。有些團隊尚沒有能力將實現他們“完成”定義的所有要求都包含在內。這一點必須告知產品負責人。產品在實現、投入使用之前要把所有的剩餘工作都完成。
提示：“未完成”的工作常常會累積到產品待辦事項列表中的條目，稱為“未完成工作”或“實現工作”。隨著這些工作的積累，產品待辦事項列表燃盡圖會比未進行累積時更精確。
提示：一些組織沒有能力在一個Sprint內構建完整的增量。這可能是因為他們還沒有自動化測試基礎結構來完成所有的測試。這種情況下，需要為每個增量創建兩種歸類：“完成”的工作和“未完成”的工作。“未完成”的工作是每個增量中需要稍後完成的部分。因為增量符合“完成”的定義，而且產品負責人同樣清楚這個定義，所以他就會知道在Sprint結束時應該檢驗什麼。“未完成”的工作會追加到產品待辦事項列表的“未完成工作”條目中，因此隨著條目的累積，就可以準確地反映到發布燃盡圖中。這個技巧為發布的進程創造了高透明度。Sprint評審中的檢驗和適應也符合這個透明的標準。 例如，如果某個團隊沒有能力對每個產品待辦事項列表條目進行性能、回歸、穩定性、安全性和集成測試，那麼這部分的工作相對於可以完成的工作（分析、設計、重構、編碼、文檔、單元測試和用戶測試）來說就被累積下來。比如說，這部分有六項“完成”的和四項“未完成”的工作，即團隊完成了一個產品待辦事項列表條目的六個單位工作（團隊根據其對如何去“完成”的理解基礎上估算），那麼當工作完成後，就在“未完成工作”產品待辦事項列表條目中追加四個單位的工作。Sprint一個接一個進行，每個增量的“未完成”工作也就累積起來，這些累積的工作必須在產品發布之前得到解決。未完成工作以線性累積，儘管事實上這些工作根據不同組織特性會呈指數形式累積。發布Sprint可以追加到任何發布末尾，以解決“未完成”的工作。因為“未完成”的工作不是以線性形式增加的，因此追加的Sprint數目是不可預知的。
敏捷和Scrum基础
推薦閱讀未免也太多orz
谢谢你的评论
大大不用刪除拉，抱歉，我的意思是說居然大大找了或看了那麼多資源，很強的意思，不是說放了太多
iThome鐵人賽
看影片追技術